You want to use the Software Update Manager 2.0 for the downtime-optimized conversion to SAP S/4HANA, that is, you want to significantly reduce the technical downtime for the conversion of your SAP system to SAP S/4HANA (on-premise edition).

SUM, Software Update Manager, S/4HANA, conversion, downtime-optimized

The downtime of the system conversion procedure is influenced by the size of the source system, and by the time it takes to convert the table content from the old tables to the new tables of the simplified data model of SAP S/4HANA. The downtime-optimized conversion procedure conducts a part of the data conversion in the uptime processing, which significantly reduces the overall business downtime.

The downtime-optimized conversion procedure will partly move the data conversion to uptime, especially:

• Table conversion for FIN, MM-ML, MM-IM is moved to uptime
• Field conversion for KONV and VBFA table is moved to uptime

In addition, it is possible to move the migration of dedicated large application tables to uptime (tables which are not affected by the conversion from old to new data model). This is based on the approach for downtime-optimized DMO, see SAP Note 2547309, and only relevant for source systems on non-HANA databases.

The changes created by end user activity in uptime are recorded and replayed by database triggers. It is not possible to give an easy estimate on the possible reduction of the downtime without further detailled investigation and test runs, as several factors influence the procedure.

General Prerequisites 

• Target product: SAP S/4HANA 2020 FPS00 (and higher stacks or releases)
• Target SAP HANA database version: SAP HANA 2.0 SP 04 rev 46 (or higher)
• If the source system is already on SAP HANA, it must be SAP HANA 2.0 SP 05 rev 52 (or higher)
• if the source system is already on SAP HANA and uses scale-out, the approach is currently not supported
• Source system: Unicode only (like for standard system conversion)
• Your source system must fulfill the SAP Kernel requirements for TCR as listed in the following SAP Notes
• SAP HANA: SAP note 2706055
• Oracle: SAP note 2698521
• IBM DB2 for LUW (DB6): SAP note 2700555
• IBM DB2 z/OS: SAP Note 2723627
• MS SQL: SAP Note 2728988
• The technical procedure requires that you execute a complete standard conversion run at least on the very first system of your landscape (for example sandbox or development).
• If your source system is not yet on SAP HANA database, you have to consider the requirements and restrictions described in SAP Note 2547309 for downtime-optimized DMO with SUM 2.0.
• To execute the approach, you need a consultant as part of the project that has successfully taken the ADM329 training and passed the related assessment.

Restrictions and Limitations:

Interference with other SUM scenarios

• "DMO with System Move" is not possible for downtime-optimized conversion
• Using downtime-optimized Conversion for a migration across data center is not supported (PAS host and DB host in different data center);
  but SAP is currently investigating possibilities and boundaries of combining this, see respective text in SAP Note 3106947, section "General Release Restrictions and Limitations"

Source database types currently supported:

• SAP HANA
• Oracle
• IBM DB2 for Linux, UNIX, and Windows (DB6)
• IBM DB2 z/OS
• MS SQL
  [We evaluate to support further source database types with later SUM 2.0 SP versions, e.g. SAP ASE, SAP MaxDB]

Application specific restrictions

• For source database SAP HANA, account based CO-PA (account based profitability analysis) must not be used in the source system

Source product version

• SAP Simple Finance 1503 and SAP S/4HANA Finance 1605 are not supported as source product version for downtime-optimized conversion

Start of application servers on DB2/DB6

• On systems running with DB2/DB6 database, application servers must not be started or restarted between the phases MODPROF_IUUCHOOK and SQLRUNTASK_RRC_HOOK.

MFLE / DIMP-LAMA

• Source systems with MFLE / DIMP-LAMA active are not supported

For more prerequisites and restrictions for MM-IM, see SAP Note 2281657.

For more prerequisites and restrictions for SFIN, see the dowtime-optimized Conversion guide that is available in the SAP Help Portal:
Downtime-Optimized Conversion To SAP S/4HANA Using SUM 2.0 - SAP Help Portal

The downtime of the system conversion procedure is influenced by the size of the source system, and by the time it takes to convert the table content from the old tables to the new tables of the simplified data model of SAP S/4HANA. The downtime-optimized conversion procedure conducts a part of the data conversion in the uptime processing, which significantly reduces the overall business downtime.

The downtime-optimized conversion procedure will partly move the data conversion to uptime, especially:

• Table conversion for FIN, MM-ML, MM-IM is moved to uptime
• Field conversion for KONV and VBFA table is moved to uptime

In addition, it is possible to move the migration of dedicated large application tables to uptime (tables which are not affected by the conversion from old to new data model). This is based on the approach for downtime-optimized DMO, see SAP Note 2547309, and only relevant for source systems on non-HANA databases.

The changes created by end user activity in uptime are recorded and replayed by database triggers. It is not possible to give an easy estimate on the possible reduction of the downtime without further detailled investigation and test runs, as several factors influence the procedure.

 

 This SAP Note contains all relevant content that you need in order to perform a downtime-optimized conversion to SAP S/4HANA:

Preparation and Execution of the Downtime-Optimized Conversion to SAP S/4HANA

• Using downtime-optimized conversion 
• You start the SUM procedure as usual, providing the location of the stack.xml file on the first SUM dialog
• On the second SUM dialog Scenario Strategy, you select downtime-optimized, then downtime-optimized Conversion 
• On the following dialog Authentication of Scenario, you have to enter a password then.
  The password will be provided via incident request which specifies the assessment badge.

For all preparation steps, follow the instructions under the Preparation section of the "Downtime-optimized DMO with SUM 2.0" SAP Note 2547309  (SUM 2.0).

Asset Accounting short term lock

• During the Preprocessing roadmap step, a short term lock of Asset Accounting is required. Consider this in the project plannnig. For more information, see sections "Downtime and Business Restrictions" and "Phases Specific to Downtime-Optimized Conversion" of the dowtime-optimized Conversion guide.

Impact Analysis

• Impact Analysis is mandatory for the execution of downtime-optimized conversion as described in SAP Note 2481983  and 2402270.

Archiving

Before the conversion:

Before the conversion of the production landscape starts, do archive as much as possible of your data due to the following reasons:

• To reduce the data volume that need to be converted
• Previous booking periods might contain inconsistant data that can lead to increased effort during the SAP S/4HANA conversion project

During the conversion:

CAUTION: The following archiving objects must not be used for archiving during the conversion,
otherwise, migrated and converted data might be archived and deleted that must be replicated and converted again during the downtime!

Delta load and replication test

It is recommended to simulate productive activity in the sandbox environment using LoadRunner tools or database scripts to test the ChangeRecord&Replay mechanism and the delta processing within the technical downtime.

Delta Load Verification requires virtualization and isolation of clone

The concept of Delta Load Verification (as explained in ADM329 training) aims to simulate the downtime of the approach on production-like hardware. It creates a clone of the production system at the time of the downtime dialog. This only works if the clone is created using virtualization, so that the clone is identical from perspective of SUM (e.g. same host names). In addition, the clone must be completely isolated from the network of the production system.

Performance of phase SQLRUNTASK_FDCT_TRANSFER_DIRECT on SAP HANA

The Fast Data Copy transfer, which is executed in the phase SQLRUNTASK_FDCT_TRANSFER_DIRECT has a high impact on the performance of the SAP HANA database. Especially the I/O performance of a productive system needs to be monitored during the execution of this phase.
A good starting point for a health check of your SAP HANA database is SAP Note 1999993, which describes how to use and interpret the results of the SAP HANA mini checks.

To ensure a stable and consistent data copy, as of SUM 2.0 SP10 patch level 4, SUM by default sets the number of processes for the execution of the SQL statements of the phase SQLRUNTASK_FDCT_TRANSFER_DIRECT to 2, which has been tested and validated by SAP.

In case you have serious business requirements to minimize the runtime of the phase SQLRUNTASK_FDCT_TRANSFER_DIRECT and a performance analysis of the productive system’s SAP HANA database shows that more parallel processes can be used without impacting the performance and stability of the SAP HANA database, the number of parallel DDL processes can be increased:

Create the file <DIR_PUT>/abap/bin/SAPup_add.par if it does not exist already and add the following line to increase the number of DDL processes:
/SQLRUNTASK_FDCT_TRANSFER_DIRECT/HDB/parprocs/DDL = <numer of parallel processes>

Remark: Please also consider the load on the productive system during this analysis. Setting the number of DDL processes to a higher value can lead to a massive impact on the productive system and a significant database slowdown.

Problems During the Conversion

 ----------------------< D039661 OCT/26/21 >-----------------------------

SUM fails in phase “PARRUN_SMIG_SFIN”

Symptom:During Conversion to S/4HANA 2021 FPS00, SUM fails in phase "PARRUN_SMIG_SFIN with the following error message:

"Last error code set:

1 error during parallel execution of processes, check 'PHASE_PARRUN.ELG' for
details
ERROR:
The following errors were detected in the log files:

# Find the detailed information in log 'FINS_MIG_FULL_001.CJF':
A4 EUPGBA 041 Report name ...: "FINS_UPG_MIG_START" Component: "FIN-MIG" "(SAP Simple Finance data migration)"
A4 EFINS_FI_MIG 608 Migration run started by user "DDIC" at "29.07.2021" "10:05:00"; mode: "FULL"
A4 EFINS_FI_MIG 602 Migration activity "AAA" started at "29.07.2021" "10:05:00"
A4 EFINS_FI_MIG 603 Migration activity "AAA" ended at "29.07.2021" "10:05:41"
A4 EFINS_FI_MIG 602 Migration activity "CCS" started at "29.07.2021" "10:05:41"
A4 EFINS_FI_MIG 607 The following errors have occurred ("1" error messages in total):
A2EEFINS_ACDOC_CUST 307 Make sure that ledger "**" and ledger group have the same name"**""**""**"

A4 EFINS_FI_MIG 603 Migration activity "CCS" ended at "29.07.2021" "10:06:09"
A2EEFINS_FI_MIG 605 Migration run stopped by errors in activity "CCS"

Solution: Implement SAP Note 3087400 in your SAP system.

 ----------------------< D037566 JUN/17/22 >-----------------------------

SUM fails in phase “RUN_RSPTBFIL_NZDM_CLASSIFY”

Symptom: During Conversion to S/4HANA using downtime-optimized Conversion approach, SUM fails in phase "RUN_RSPTBFIL_NZDM_CLASSIFY with the following error message:

"Last error code set:

1 error during parallel execution of processes, check 'PHASE_PARRUN.ELG' for
details
ERROR:
The following errors were detected in the log files:

A4 ENZDM 036 SFM classification for table KONV started
A4 ESFM 068 Table KONV has a new tablename and will be renamed to PRCD_ELEMENTS
A4 ESFM 017 Table KONV is defined as primary SFM Table
A2EESFM 070 Table KONV cannot be handled by SFM due to active SLT trigger on table KONV"

Reason: SLT triggers on ShadowField tables cannot be handled in uptime as of now.

Solution: Possible mitigations are

1. Suspend SLT scenario which contains the effective table during SUM uptime, so that SLT trigger is dropped
2. Reset SUM and disable Shadow Field Handling. This will require additional downtime as tables are converted in technical downtime 
• add the following line to SUM/abap/bin/SAPup_add.par
  IOC_OPTION=OFF

Chronological Summary

Date................Section...........Short description
-----------------------------------------------------------------------

17/JUN/2022 ... Solution ... SLT trigger handling on Shadow Field Tables like KONV and VBFA
24/FEB/2022 ... General ... No support to combine approach with data center move
26/OCT/2021 ... Solution ... Problems During the Conversion
07/OCT/2021 ... Solution ... List of archiving objects updated
30/JUN/2021 ... Solution ... Comment on Delta Load Verification
22/JUN/2021 ... General  ... Initial release of SAP Note